flowchart TD
U["👤 使用者<br/>（活動報名 / 服務紀錄）"] -->|填寫送出| F1["📋 活動報名表"]
U -->|填寫送出| F2["📋 服務紀錄表"]
F1 -->|表單一送出就啟動| T["🔄 自動整理程式"]
F2 -->|表單一送出就啟動| T
T -->|寫入| S["📊 Google 試算表"]
S --> R1["✨ 整理後的報名資料"]
S --> R2["✨ 整理後的紀錄資料"]
R1 --> D["📈 Dashboard<br/>報名人數 / 出席率<br/>服務時數 / 分類統計"]
R2 --> D
style U fill:#e1f5ff,stroke:#0891b2
style D fill:#fff4e6,stroke:#f59e0b
style T fill:#f0f0f0,stroke:#666
從一段話到完整表單系統：用 Codex + clasp 建立報名表、紀錄表與 Dashboard
AI工具
Codex
Apps Script
自動化
表單
接續上一篇，把 clasp 連線後的 Apps Script 真的拿來做事：一段話交給 AI，自動生出報名表、服務紀錄表、資料整理表與統計 Dashboard，之後想調整只要重跑一次不會壞掉。
上一篇 用 Codex + clasp 自動建立 Google 表單與統計分析 是把電腦、clasp、Google Apps Script 這三邊接起來。這一篇要用這條線做真正的事：只丟一段中文說明給 Codex，讓它幫你做一整套「兩張表單 + 資料整理 + 統計 Dashboard」的系統，最後你只要按一顆按鈕，全部東西就一次建好。
整個過程分四步：AI 產生程式 → 推到 Google 雲端 → 執行 → 測表單看結果。
目標系統
先看做完會長什麼樣、東西怎麼串起來：
拆開來說就是這幾件事：
- 兩張 Google 表單：一張給活動報名（姓名、Email、場次…），一張給服務紀錄（日期、服務類型、時數…）
- 一份 Google 試算表：兩張表單的答案都會存進來，同一份檔案
- 一個「自動整理」的程式：只要有人送出表單，這支程式就會被啟動，把新資料整理乾淨後放到指定工作表
- 一頁 Dashboard：試算表裡最後一頁，會自動算出「今天報了幾人」「總服務時數多少」這類統計
寫這一整套要花多久？ 一段中文說明給 AI，AI 幫你寫程式，跑一次按鈕，全部做完 —— 大約 10 分鐘。
交給 Codex 的那段話
以下就是實際丟給 Codex 的說明。看不懂裡面的專有名詞沒關係，重點是感受一下「用中文條列你要什麼」這件事有多直接：
請讀取目前的 clasp Apps Script 專案，建立一個可重複執行的
setup()：
- 建立「活動報名表」：姓名、電子郵件（格式驗證）、參加場次（上午 / 下午）、飲食需求（複選）、個資同意（必填）
- 建立「服務紀錄表」：服務日期、人員/個案 ID、服務類型（下拉）、服務時數（數字）、紀錄摘要（段落）
- 兩張表單的回應寫入同一份 Google 試算表
- 保留表單原始回應工作表，不直接修改
- 建立「整理後的報名資料」、「整理後的紀錄資料」、「Dashboard」三張工作表
- 有人送出表單時，自動把資料清理、把日期跟數字轉換好、產生一組編號
- Dashboard 顯示報名人數、出席率、服務時數、紀錄完成率、每週趨勢與服務類型分布
setup()再執行一次，不能重複建立表單、試算表或觸發器- 把表單和試算表的識別碼存起來（下次執行時能認得同一份）
- 印出表單填答網址、編輯網址、試算表網址
- 加上使用說明、測試清單、錯誤處理與註解
- 完成後執行
clasp status，列出新增與修改的檔案
為什麼這幾條特別重要
看起來這只是一串條列，但有幾條如果不寫進去，系統之後會愈用愈亂：
| 條號 | 說的是什麼 | 不寫會怎樣 |
|---|---|---|
| 第 4 條 | 表單的原始答案要保留 | 之後如果整理程式改了，想重新處理舊資料就沒得處理 |
| 第 6 條 | 表單送出當下就自動整理 | 你會一直手動整理，或每小時才更新一次 |
| 第 8 條 | 重跑不會重複建立 | 每改一次程式就會多建一份表單，跑三次雲端會有三份，愈跑愈難管理 |
| 第 9 條 | 記住表單和試算表的身分 | 每次重跑都把識別碼寫死在程式裡，一改就要手動改 |
這幾條是踩過坑才知道要寫的。這也是「用 AI 寫東西」跟「AI 亂寫一通」的分界線 —— 你能不能把過去踩到的雷寫進說明裡。
執行流程（4 步）
1. AI 產生程式 + 推到雲端
丟完那段說明，Codex 會生出幾個程式檔（負責建表單、整理資料、算 Dashboard 各一個），並自動用 clasp push 這個指令把程式推到 Google 雲端。
推完你打開 Google Apps Script 網頁編輯器，會看到剛剛沒有的檔案都出現了。
2. 執行 setup() + 授權
在 Apps Script 網頁編輯器裡選 setup 按執行。第一次執行一定會跳一個 Google 授權視窗，問你「這個程式想使用你的表單和試算表，可以嗎？」
會跳這個視窗是因為程式要幫你建東西，Google 不會讓程式偷偷做，一定要你手動點同意。點完就繼續執行。
執行完的畫面會告訴你：試算表在哪、兩張表單在哪，各有一組網址：
點試算表網址 → 會看到 Google 試算表裡多了對應的工作表。點表單網址 → 會看到剛做好、可以直接發給別人填的表單。
3. 測表單
打開報名表看看：
自己送幾筆假資料進去，回試算表看有沒有動靜：
- 原始回應那張 → 一定會有你剛送的資料（Google 表單本來就會存）
- 「整理後的報名資料」那張 → 也要有 → 這樣才代表「送出當下自動整理」有接好
如果只有前者、沒有後者，代表自動觸發那條線沒接好，回頭跟 Codex 說「表單送出沒有觸發整理程式，幫我修」。
服務紀錄表也一樣，送幾筆看：
4. 看 Dashboard
送幾筆測試資料之後，打開試算表裡的 Dashboard 那張工作表：
上面四個大數字（報名人數 / 出席率 / 服務時數 / 紀錄完成率）要跟你剛送的假資料對得上。對不上通常是「整理程式的欄位順序」跟「Dashboard 讀取的欄位順序」對不齊 —— 回頭跟 Codex 說「Dashboard 上的服務時數是空的，幫我檢查欄位對應」。
三個關鍵設計選擇
這幾個決定看起來像技術細節，但會影響「你之後改需求會不會很痛苦」：
設計成可以重跑，是這套架構的核心。 實務上你一定會反覆改需求 —— 多加一個欄位、換一個 KPI、想再開一張表。每改完直接重跑 setup() 就好，它會認得「這份表單已經存在」，只更新差異、不會重建。你可以自由改，不用擔心弄壞。
資料整理選「送出當下就處理」。 有兩種方式可以整理表單資料：一種是送出當下就整理（每筆資料進來就跑一次），一種是定時整批處理（例如每小時把新資料一次整理好）。這個系統選前者，理由是資料一送出就能在 Dashboard 上看到，測試時反應直覺。定時整批處理則適合資料量非常大、或整理過程需要跑很久的情境。
Dashboard 選「試算表公式」，也可以改成用程式算。 這個系統的 Dashboard 是靠試算表公式（SUM、COUNTIF、AVERAGE 等）自動彙總 —— 你只提供版面，資料一進來公式就自動更新。另一種做法是用程式計算好結果再寫回去，適合統計邏輯太複雜、公式寫不出來、或資料量大到公式跑不動的情況。兩種都可以，看你要維護的是「試算表版面」還是「程式邏輯」。
適合的場景
同一套架構，換個表單欄位就能搬到：
- 活動報名 + 出席紀錄（原場景）
- 個案管理紀錄（社工、輔導、健檢）
- 志工排班 + 服務時數
- 課程簽到 + 學習紀錄
- 內部工作日誌 + 週報統計
只要換一份「給 Codex 的說明」就好，程式的骨架完全一樣。
小結
這篇的重點不是「原來 Apps Script 這麼強大」，而是：
當你把踩過的坑寫進給 AI 的說明裡，AI 就能一次幫你把系統做對。
以前試錯的成本是「自己寫程式 → 出 bug → debug」，現在變成「改一句說明 → 重跑一次按鈕」。這是完全不同層級的效率。
下一步可以繼續讓這套系統做更多事 —— 有人送出表單當下就寄確認信、每天定時把週報寄給主管、把資料同步到別的分析工具。都只是再多一句話給 AI 而已。
從教學範例到可導入系統
教學範例可以用 10 分鐘做出原型；正式導入時，真正重要的是原始資料保留、欄位規格、通知紀錄、重跑機制與後續維護。